Subject: DLSw minutes - June meeting

From: [email-masked]
Date: Thu, 7 Jul 94 07:38:25 PDT

Data Link Switching Related Interest Group
APPN Implementers Workshop
Meeting Minutes - 27-29 June 1994

I.  Administration

    A.  Opening
The RIG chair, Louise Herndon Wells of Internetwork Technology 
Institute, opened the meeting with a short presentation on 
elements of the consensus model.  A second part of this 
presentation was delivered on the second day of the DLSw meeting.  
Both parts are combined here.    

        1.  The consensus process strives to obtain the highest-
quality decisions and group experience through the broadest 
perspective.  Although theconsensus process may take more time up-
front, it takes less time in thelong run because the decisions 
take into account all viewpoints so there is less resistance and 
reopening closed discussions.  In addition, because each person is 
encouraged to participate and all input is valued, participants 
are more satisfied and the meetings are more productive.

        2.  Three Ingredients for Successful Meetings
             Common goals
             Clear process to meet those goals
             Sense of involvement, being heard, being involved by
                  all participants

        3.  Group Member Skills
             Listening
             Flexibility
             Separation of Idea from Individual - non-attachment
                 to our own ideas and learning to separate 
                 personalities from ideas.

        4.  Six Shared Responsibilities of Facilitator & 
                  All Members
             Refocusing - if the group veers off the topic
             Clarification - request if a point is unclear; 
                  clarify if not understood
             Summarizing - synthesize the discussion points
             Identifying new issues - suggest discussing under 
                  separate agenda item
             Ensuring that all viewpoints are heard - respect 
                  equally all contributions, encourage quiet 
                  members
             Identifying process difficulties - mention when 
                 disagreement may be about process instead of 
                 topic of discussion 

        5. Reaching Consensus
            Conflict is inevitable; fighting is a choice
            All viewpoints are heard
            A proposal is presented (usually by facilitator) when 
                consensus seems to be emerging
            Amendments are made to proposal as necessary to 
                address concerns

        6. Dealing with significant concerns 
            If one or more parties have significant concerns about 
                proposed consensus,they signal their level of 
                disagreement with fingers:
                  Five fingers is for total agreement
                  Four fingers indicates minor reservations
                  Three fingers represents more concern
                  Two fingers illustrates significant objection
                  One finger is for major disagreement
                  A fist (no fingers) means that the participant 
                    is unable or unwilling to accept the proposed 
                    consensus

            Few fingers for any party and/or a significant number 
                 of participants using less than five fingers may 
                 indicate a lack of readiness for consensus.
            In all but the last case (no fingers), consensus could 
                 be considered reached, but the fewer the fingers,
                 the more the facilitator should attempt to
                 continue efforts to resolve concerns.
            In all but the last case, the participants with 
                 disagreement are accorded the time necessary to 
                 express their concerns and work toward a
                 less objectionable proposal.
            In all the but last case, the objecting party agrees 
                 to abide by the group decision, and not to 
                 undermine or continue to fight it, and the group
                 agrees to keep the party's concerns in mind.
            In the last case (no fingers), consensus has not been 
                 reached on the current proposal.  An alternate 
                 proposal may be developed, discussion may 
                 continue, or the topic may be tabled until later.

        6.  Ten Meeting Values
             Cooperation - a competitive atmosphere is not 
                  conducive to unity.
             Diversity - the broadest range of viewpoints is 
                  striven for.
             Feelings - the whole person, including feelings and 
                  intuition, is honored.
             Lack of Authority - every person has a piece of the 
                  truth.
             Equalization of power - a balance of influence by all 
                  is sought for.
             Conflict - considered healthy and something to be 
                  worked with.
             Mutual trust - extended toward all with respect.
             Common ownership of ideas - individual sharings are 
                 contributions and become building blocks for the
                  whole group.  based on theory that the 
                 group process itself contributes to the 
                 development of ideas in a participant.  
             Group process - the way the group works together to 
                 make decisions or exchange information is valued, 
                 not just the decisions themselves.
             Self-teaching - having mechanisms in place to 
                 continually foster improvement of meeting 
                 quality through skills enhancement.

        7.  We agreed, near the end of the meeting, to accept  
            these guidelines as ourguidelines for consensus in 
            our meetings.

    B.  DLSw Status
Louise Herndon Wells presented a proposed status and schedule to 
reach closed pages (CP) on Version 1 of the DLSw standard.

-  Due to summer vacation schedules, we decided on a three-week 
review cycle for each level.

-  Two notifications will be sent notifying participants that a 
review document has been posted (in case a single message is 
lost).  The poster will also watch for non-delivery replies and 
work with the AIW mail-exploder manager to ensure delivery.  The 
participants are responsible for responding during that period -- 
a non-response will be considered approval.  

-  If there are major changes, the review cycle may be extended.

-  Until the AP document level, the editor is granted discretion 
to change the document to reflect our agreed-upon changes as he 
sees best.

-  With regard to DLSw Version 1, this group reached consensus on 
the network last month to post it as an informational RFC rather 
that present it as a proposed draft standard to the IETF.  
Therefore, this issue was not discussed at this meeting.

        1.  DLSw Version 1 will include changes developed by three 
             RIGlets:  Connect, Flow Control, and Capabilities.

        2.  DLSw Version 1 may include a Priority section also,
             if the IBM proposal is approved within the three-
             week AD review cycle.

        2.  DLSw Version 2 is expected to include changes 
             developed by three other RIGlets:  Priority/COS, Loop 
             Prevention, and Conformance, plus any new material 
             from Connect, Flow Control, and Capabilities.

        3.  The DLSw MIB will be a separate document developed by 
              the DLSw MIB RIGlet.  A proposed MIB approval 
              schedule was proposed in the MIB RIGlet meeting,
              and is presented in that section of the minutes.

        4.  Approved Direction
             The goal of this meeting was to reach a level of 
             Approved Direction or begin the AD review cycle.

             The proposals presented by the 
             coordinators of each of the three RIGlets prior 
             to this meeting were incorporated into the original
             RFC 1434 and distributed at this meeting.  (The 
             Capabilities RIGlet will also post a Capabilities 
             Exchange Protocol proposal in addition to its
             Capabilities Exchange Format proposal, including 
             relevant text to support DLSw capabilities.) 

             The changes made to these proposals at this meeting 
             will be made to this document by our editor, Alan 
             Bartky of Sync Research, to create our first complete 
             proposed AD document.

             The new priority proposal will be written up and 
             submitted also for inclusion in this proposed AD 
             document.

!!!>          Any changes decided on at this meeting which 
!!!>          participants have taken as action items to write up 
!!!>          must be posted by Tuesday, July 5, at the latest 
!!!>          (hopefully earlier). 

             This document will be posted by July 11 for comments 
             as the proposed DLSw Approved Direction document.
             Comments, discussions, and feedback will be accepted 
             for three weeks, until July  29.

             Unless there are necessary major revisions in that 
             time, the posted document, with the inclusion of 
             changes during the comment period, will be considered 
             our approved AD document.

             The editor will post this approved AD document by 
             August 5.

        5.  Approved Pages - The AD document, with the included 
             changes, will be the proposed AP document.
             This document will be posted by August 5.
             Comments will be accepted for three weeks, until 
             August 26.  

             Unless there are necessary major revisions in that 
             time, this document with the agreed changes will be 
             considered our approved AP document.  The editor will 
             include all agreed-upon changes to the proposed AP
             document and post it by September 2.

             Vendors should be able to develop products based on 
             this AP document, since only minor points or 
             discovered errors will be changed at this point.

        6.  Closed Pages 
             The final AP document, with the agreed changes, will 
             be the proposed CP document.
             This document will be posted by September 2.
             Comments will be accepted for three weeks, until 
             September 23.
             Unless there are necessary major revisions in that 
             time, this document with the agreed changes will be 
             considered our approved CP document and the DLSw 
             Version 1 document.

             The editor will include all agreed-upon changes to 
             the proposed AP document and post it by September 30.

        7.  AIW and IETF Informational RFC
            After DLSw Version 1 has reached CP, the DLSw chair 
            will inform the AIW chair of our completed status.  
            This notification will be both by electronic mail and 
            at the AIW meeting in October.
            DLSw Version 1 has reached CP, the DLSw editor will 
            request an informational RFC number from the IETF and 
            will post the document as an informational RFC.

       8.  DLSw Version 2
            Work on Version 2 must continue while Version 1 is 
            going through the approval process, especially in 
            Priority/COS, Conformance, and Loop Prevention.
            These RIGlet coordinators should manage their groups 
            to encourage proposals and discussion such that, at 
            the October AIW meeting, we can schedule AD status 
            for Version 2.  This would mean, at best, a complete, 
            discussed proposal posted by September 30 at the 
            latest (13 weeks from now) and, at least, a proposal
            or proposals covering each of the areas under 
            consideration.  The group agreed that MIB work should
            get priority over Version 2 efforts.  The chair 
            strongly encourages the coordinators to foment an 
            initial proposal by the end of July, to be enhanced in 
            the following two months.

    C.  Approval of Agenda

        I.    Administration
              A.  Opening
              B.  Status
              C.  Approve Agenda
        II.    Connect RIGlet
        III.   MIB RIGlet
        IV.    Flow Control RIGlet
        V.     Capabilities RIGlet
        VI.    Loop Prevention RIGlet
        VII.   Priority/COS RIGlet
        VIII.  Conformance RIGlet
        IX.    Closing
               A.  RIGlet summaries: consensus items, open 
                      issues, status
               B.  RIG schedule to CP for Version 1
               C.  General Planning for Version 2

        Agenda was approved as proposed.

II.  Connect RIGlet

    A.  Handouts
The new finite state machines (FSMs) were posted prior to the 
meeting on June 6.  They can be reached by anonymous FTP at 
networking.cary.ibm.com (formerly ibmstandards.cary.ibm.com) in 
/pub/standards/aiw/dlsw/connect.  They were not 
handed out at the meeting.

Steve Klein of IBM, coordinator of the Connect RIGlet, distributed 
copies of his sample connection flows.  This document will be 
posted to the same area.

    B.  Discussion of open issues

        1.  Consensus was reached on new session set-up as 
proposed by Steve Klein of IBM on the network.

        2.  Consensus to include support for non-activation XID.

        3.  Propagation of Routing Control Field Largest Frame 
bits in switch-to-switch (SSP) messages.  A proposal was made on 
the network by Wayne Taylor of IBM and no comments were received.  
Although there are still some issues with them (e.g., caching), 
consensus was reached to keep them.  The proposed AD document will 
be posted without further comments.

Frank Bordonaro of Cisco, Paul Brittain of DCL, Scott Barvick of 
Wellfleet, and Wayne Taylor of IBM will post comments on this 
topic during the AD review cycle.

        4.  Obsoleting old flows
At the last meeting, obsoleting ENTER_BUSY, EXIT_BUSY, 
TEST_CIRCUIT_REQUEST, TEST_CIRCUIT_RSP was discussed.  In the new 
state machines, the first two are deleted and the last two remain 
in.  However, a standard DLSw box must be able to respond to an 
ENTER_BUSY -if- it wants to support connections to a 1434-based 
DLSw box.

        5.  Varying correlators and IDs during circuit set-up
Paul Brittain of DCL had noted that Data Link Correlators, Port 
IDs, and Transport IDs may vary during circuit set-up.  Steve 
Klein posted a proposal and there was no response, so it was 
discussed here.  Consensus as follows:

            a.  Target Data Link Correlator, target Port ID, and 
                target Transport ID shall remain the same once the 
                target DLSw has sent it in a ICR_cs.

            b.  Origin Data Link Correlator, origin Port ID, and 
                origin Transport ID shall remain the same once the 
                origin DLSw has sent it in a REACH_ACK.

            c.  Paul Brittain will post the words necessary to 
                support this decision by July 4.  If received in 
                time by Alan Bartky, it will be included in the 
                proposed AD document.  Otherwise, it will be 
                considered a comment to it.

        6.  NetBIOS names
Steve Klein made a proposal to support 15 and/or 16 byte NetBIOS 
names.  There were some comments.  Consensus as follows:

            a.  16 bytes are significant for searches across the 
                WAN and for matching NAME_QUERY to NAME_RESPONSE.

            b.  We will not include in the document anything on 
                caching NetBIOS names because it does not affect 
                interoperability.  (The proposal had recommended 
                that a vendor may choose to cache and, if caching 
                is used, at least 16 bytes should be cached, 
                though the vendor may choose to cache only 15).

        7.  Handling NetBIOS NAME_QUERY retries
How long should NAME_QUERY retries be absorbed (considered retries 
and so not propagated on the WAN)?  How will retries be 
identified?  Consensus:

            a.  Up to implementation to decide what is a retry and 
                what is a new query.

            b.  Origin should absorb retries based on repetition 
                of a pair of 16-byte names (origin and 
                destination).

            c.  The target should do local retries in a manner 
                appropriate to the data link in use.

            d.  Gene Cox of IBM will write up the wording for this 
                consensus by 7/5.

        8.  SSP header length field in a common location
Frank Bordonaro of Cisco made a proposal on this and received 
feedback on the network, including a proposed one-byte field.  
Consensus was reached as follows:

            a.  There should be an SSP header length field.

            b.  In the information message, it will be carried in 
                the currently reserved field right after version 
                number.  This field was recently requested by the 
                Flow Control RIGlet to carry a pacing indicator, 
                but Shannon Nix, Flow Control coordinator, agreed 
                to move his group's indicator to the next 
                available reserved field.

            c.  In the control message, the header length field 
                will be moved up to the currently reserved field 
                right after version number.

            d.  In the control message, the second instance of the 
                message length will be replaced as a reserved 
                field.  Gene Cox of IBM noted that the second 
                instance was never used by the 6611 so the field 
                can be reused.

            e.  Alan Bartky will write up the appropriate words 
                for this agreement and include it in the AD draft.

         9.  SDLC scenarios in state tables
Participants had reviewed the state tables Steve had posted and 
agreed to accept them.  It was agreed that they should all be 
included in the proposed AD document.

       10.  Flow examples (handout)
The ten examples included:
(1)   DLSw bring-up with XIDs (generic)
(2)   mapping LAN events to the DLC events and actions on Flow (1)
(3)   like (2) but for implementations preferring to respond to 
         SABME immediately
(4)   DLSw bringup without XIDs (circuit setup) (generic)
(5)   mapping LAN events to the DLC events and actions on (4) and 
         adding a NETBIOS_NQ_ex and NETBIOS_NR_ex
(6)   leased SDLC PU 2.0 as origin station (will use flow similar 
         to (4) since other side's data link is unknown)
(7)   switched SDLC PU 2.0 as origin station
(8)   leased SDLC PU 2.0 as the target station
(9)   switched SDLC PU 2.0 as the target station
(10)  SDLC T2.1 device as the target station.  (SDLC T2.1 origin 
         station would look just like the LAN T2.1 origin station.

It was noted that there is tremendous variability in SDLC 
implementations, so these examples are helpful to start with but 
are not comprehensive.  For example, some SDLC implementations 
will die if they receive an XID.

Alan Bartky volunteered to write up the words to accompany these 
flow diagrams by 7/8.

    C.  Summary
Except for writing up the text to support the decisions the group 
made, there are no open action items for the connect RIGlet and it 
is ready to propose for AD.  

III.  MIB RIGlet

(Note:  The MIB RIGlet met at three separate times throughout the 
meeting.  All of the discussion is summarized here.)

    A.  Selecting an editor and a new coordinator
Louise Herndon Wells, DLSw chair, reminded the group of the mail 
message noting the retirement of Glenn Aikens as coordinator for 
this RIGlet.  She also noted that, since the MIB would be a 
separate document from the DLSw document, this RIGlet will need 
its own editor.
Nominations were opened for coordinator and editor.

        a.  David Chen of IBM ([email-masked]) was nominated 
            and approved as DLSw MIB editor.

        b.  Deirdre Kostick of Bellcore ([email-masked]) 
            was nominated and approved as DLSw MIB coordinator.  
            After being selected, Deirdre managed the remainder of 
            the MIB meeting.

    B.  Scope of work
Though called the MIB RIGlet here and on the mail exploder, this 
group will also develop work for coordination with SNA Management 
Services (SNA/MS) as well as Simple Network Management Protocol 
(SNMP).  SNA/MS management is not a current work item.

    C.  Handouts
David Chen of IBM, new RIGlet editor, handed out a proposal from 
IBM for a structure and tables for the DLSw MIB.  This handout 
will be emailed to the group and/or posted on 
networking.cary.ibm.com in /pub/standards/aiw/dlsw/mib.
The 6611 DLSw MIB is already posted there.

    D.  Proposal

        1.  MIB Development Process
The group agreed on the following elements of process:
    Work will be done almost exclusively on the network.
    RIGlet will disband if participation is too low
    Identify work items, define deliverable(s), goals/milestones 
for each work item, solicit contributions and comments, 
consolidate inputs into a single DLSw MIB, go through reviews and 
revisions.

        2.  SNMP MIB Schedule
Consensus was reached to aim for the following schedule:

06/29/94    (Assume DLSw Version 1 is essentially at AD status)
07/15/94    All RIGlets and vendor MIBs/sketches posted
on going    aiw-dlsw-mib mailing list discussion
08/15/94    Post DLSw MIB AD draft for review
09/15/94    Post revised DLSw MIB AD draft and recommend AD status
09/30/94    Achieve AD status (Assume DLSw Version 1 achieved AP 
status)
10/15//94   Post DLSw MIB AP draft (in RFC format) (AIW 6 is held)
11/30/94    Post revised DLSw MIB AP draft and recommend AP status
12/31/94    Achieve AP status 
01/01/95    Submit DLSw MIB to IETF as Informational RFC

        3.  IBM Proposal Elements

            a.  MIB Size
Current proposal has about 250 objects (and some multiply, like 
MAC lists). Deirdre Kostick noted (tongue in cheek) that, as a 
goal, the MIB should be smaller than the protocol.

            b.  Alignment
DLSw MIB work should align with RFC 1573 "Evolution of the 
Interfaces Group" and with the SDLC MIB and 802.2 MIB.

            c.  Structure
IBM's proposal presents a structure with the following groups:
Node group - qualities of the node (e.g., identity, capabilities)
Partner group - connectivity (e.g., search statistics)
Directory group - reachability (e.g., resources, cache)
Circuit group - circuit status and statistics
Link station - separate MIBs (SDLC and LLC2)
Others - virtual and non-LAN end stations
Traps - what should generate traps

    E.  Interim meeting
Deirdre Kostick will examine the feasibility of an interim meeting 
in September in Atlanta at the NetWorld + Interop show.

    F.  Enterprise-specific MIBs
The following companies will submit enterprise-specific MIBs to 
the mail list by 7/15:  Wayne Clark of Cisco, Scott Barvick of 
Wellfleet, Thang Do of Novell, David Chen of IBM, and Al Sciacca 
of BBN.  As coordinator, Deirdre will get these MIBs loaded to the 
archive.

    E.  Open issues
After reviewing the IBM proposal, the group listed thirteen areas 
of concern to be addressed on the network to develop a DLSw MIB.

Item 1: Should the MIB allow more than one DLSw entities?
        - will there ever be more than one DLSw per box (agent)?
        - if yes, will other solution satisfy the requirement?
          (e.g., each DLSw entity uses a different community name)
        - will it be too costly to allow DLSw entities in the MIB?

Item 2: Should the MIB allow transport connections other than 
TCP/IP?

Item 3: Align with DLC MIBs (SDLC, 802.2 LLC), NAU/APPN MIBs
        and pointers to those MIBs

Item 4: Should the MIB be designed for configuring data link 
switches?

Item 5: Size of the MIB

Item 6: One set of Capabilities Exchange for
        - all (e.g., one set of CapEx to be sent to all partners), 
or
        - partner dependent (e.g., one CapEx for each partner), or
        - transport type dependent (eg, one for each transport 
type), or
        - ... ?

Item 7: SNMP SET and dynamic configuration operations should be
        clearly specified.

Item 8: MIB should be consistent with DLSw protocol.
        - How does MIB map to protocol?

Item 9: Implication to NMS, e.g., MIB browser.
        A scenario:
        if the rate of entries generated in the event table is
        higher than the rate the SNMP NMS can dump the table, and
        if the NMS dump every object instance in the agent,
        then the NMS will never be able to reach the end of the 
event
        table, and the NMS will never get any object instances 
after
        the event table.

Item 10: When developing the MIB, it should always keep in mind of
        how NMS uses these objects.

Item 11: What condition that traps will get generated should be
        clearly stated.

Item 12: If it is vendor's option to implement some of the objects
        (e.g., counters), how to specify this situation in the
        MIB module?  In description clause?  Any precedent?
        (It seems that conformance clause is only used for specify
        what objects need to present when a function is 
supported.)

Item 13: Balance between
        - a minimum set of "standard" MIB with a bunch of similar
          enterprise specific objects, and
        - a large "standard" MIB with a bunch of "optional" 
objects

IV.  Flow Control RIGlet

    A.  Handouts
The proposal developed and posted last week by Shannon Nix of 
Metaplex, RIGlet coordinator, was included in the document 
distributed by Alan Bartky..

    B.  Review

        1.  Capabilities exchange - includes initial pacing 
window (IPW).

        2.  Receiver issues flow control operators to explicitly 
grant permission to send units (frames).  Current operators are 
Repeat Window (unchanged), Increment Window (+1), Decrement Window 
(-1), and Reset Window (flush to 0).  (There is an open issue to 
consider Halve Window (half of CurrentWindow).)

        3.  Receiver grants units on a cumulative basis.

        4.  Sender acknowledges receipt of operator on subsequent 
frame (usually piggybacked on data).

        5.  Shannon presented  flow diagrams three examples of 
flow control:  fixed flow, reset window, and adaptive flow.

    C.  Open issues

        1.  Feedback mechanism
It was agreed that a sender can piggyback a window grant ACK on a 
data frame.  Further, there is no need to send the ACK until the 
send has data to send.

We also reconfirmed our decision not to attempt to flow control on 
non-circuit flows.

        2.  Restore Halve Window operator?
It was agreed that some implementers might find it valuable to 
slow down traffic moderately rather than having only the options 
of decrement-by-1 or reset to zero.  Shannon will assign an 
operator value for Halve Window.

        3.  Need message type for independent flow control 
            indicator (IFCIND) and independent flow control 
            acknowledgement (IFCACK).
These flows cannot be piggybacked.  Therefore, they need their own 
message type.  Alan will assign message type.

        4.  Flow control byte moved in header due to Connect 
            RIGlet change
Connect needed the second byte in the header for header length.  
The flow control byte will therefore move to the first available 
reserved field.  Alan will input change.

        5.  Implicit/explicit grant at circuit set-up

             a.  Decision renewed to require explicit grant before 
                 sender can send.

             b.  Explicit grants can flow on other circuit set-up 
                 messages, such as ICR_cs or REACH_ACK.

             c.  All grant acknowledgments, except reset window 
                 acknowledgments, shall be piggybacked on data

             d.  Gene Cox will write-up exact wording, including 
                 messages on which grants can flow, by 7/5.

        6.  Protocol violation handling
Shannon posted a proposal of how to handle protocol violations.  
It was decided to leave it to the implementer how to handle them, 
but it was agreed to leave the protocol violations list in the 
document.  Alan will adjust wording.

        7.  Definition of "backward compatibility"
We agreed that, rather than including details on how to 
interoperate with RFC 1434 or existing 6611s, we will refer the 
implementer to RFC 1434 for information on the non-standard 
version and leave it to the implementer to decide if and how to 
operate with them.

We also decided to change the version from X'4B' (ASCII K for 
Kushi, one of the original authors) to ASCII 1.

        8.  Management considerations 

We decided to remove all flow control management text and submit 
it to the MIB RIGlet

        9.  Need more flow examples in document

Shannon presented three flows which will be included in the 
document.

       10.  Window scope (connection, per circuit) not clear in 
            text
During capabilities exchange, a pair of DLSw's will exchange an 
initial pacing window (IPW) that will be used for each circuit 
that is set up across that TCP connection.  Whenever a circuit is 
set up, a new window instance is spawned for that circuit and the 
window is equal to the IPW set for the supporting connection.  
This is unclear in the text.  Shannon will reword by 7/5.

       11.  Rationale for flow control of datagrams
Shannon will write a rationale for the text by 7/5.

    D.  Summary
Except for writing up the text to support the decisions the group 
made, there are no open action items for the flow control RIGlet 
and it is ready to propose for AD.

V.  Capabilities RIGlet

    A.  Handouts
Wayne Clark of Cisco, RIGlet coordinator, handed out a list of 13 
open issues and 23 closed issues for this group.

He also handed out the Capabilities Format Proposal which includes 
all of the agreements to date and proposed solutions for most of 
the open issues.  (The document distributed by Alan Bartky also 
included the capabilities format proposal.)

Wayne will post next week a Capabilities Protocol Proposal with 
more verbiage regarding capabilities support in DLSw, based on our 
decisions and capabilities-related information in other sections 
of the document.  

Capabilities Exchange is also abbreviated as CapEx in these 
minutes.

    B.  Open Issues

        1.  Issue 28 (was closed)
It was decided during a previous session that the capabilities 
exchange will use the long header.

        2.  New issue:  response by receiver of a negative CapEx
Consensus -- the receiver of a negative capabilities exchange 
response will bring down the TCP session.

        3.  Issue 03
We agreed to kill the MAC Addr List control vector (CV).  DLSw 
will always use MAC Addr, MAC Addr Mask.

        4.  New issue:  bit-ordering
In order to match the current RFC 1434, in which MAC addresses are 
non-canonical now, it was agreed that the organizationally unique 
identifier (OUI) and the MAC address will be non-canonical.  The 
DLSw MIB, however, will be canonical to match other MIBs.

        5.  Issue 05 - NetBIOS names (padding)
The NetBIOS name can include "don't care" (?) and "wildcard" (*) 
characters to match on a number of NetBIOS names.  Exact text is 
in proposal and was approved as proposed.

        6.  Issue 07 - DLSw Version CV
Two bytes will be used, one for version (major) and one for 
release (minor).  The first DLSw document will thus be X'0100'.

        7.  Issue 12 - Default value for number of TCP sessions
A recommendation was included in the CapEx proposal.  We decided 
to simplify it, and wait to decide how to format multiple sessions 
until we actually will use them.  We will keep two simplex 
connections as the default and one full duplex connection as a 
negotiable option.  All other values than X'01' and X'02' are 
reserved in this CV.  When making this change, Wayne will add text 
to describe simplex and duplex.

        8.  Issue 35 - How to handle disagreement on number of TCP 
sessions
A recommendation was included in the CapEx proposal.  Based on the 
consensus for issue 12, we will delete the portion of the proposal 
that relates to more-than-2 sessions.  To guarantee that a session 
is not dropped before the response is received notifying about the 
drop, the recommendation will be changed to say "drop the TCP 
session for port on which the +RSP was received."

        9.  Issue 14 - Exclusivity CV
On the net, it was noted that we need to clarify, if a DLSw sends 
a list of MAC or NetBIOS names, whether that list is comprehensive 
(exclusive) (e.g., do not ask me about others) or possibly partial 
(inclusive) (e.g., here are some; I may have more).  

             a.  We need two exclusivity vectors - one for the MAC 
                 address list and one for the NetBIOS name list.

             b.  The exclusivity CV without a MAC or NetBIOS list 
                 will require sending a CANUREACH.

             c.  We will have the option of a group or individual 
                 indicator in the NetBIOS name CV.

             d.  The proposal needs text about the danger of group 
                 names.

       10.  Issue 15 - SAP List CV requirements
A proposal was received from IBM  for the format of the SAP List 
CV.  It was agreed to accept the proposal but to reverse the 
proposed order of the list.

       11.  Issue 16 - OUI or non?
A proposal was received to allow another vendor identifier type, 
the OID tree.  It was decided to use only the OUI.  (Also, as 
agreed above, it will be in non-canonical format.)

       12.  Issue 18 - IDs for vendor-specific CVs
A recommendation was received from Peter Gayek to assign X'80' 
thru X'CF' for DLSw standard CVs and X'D0' thru X'FC' for vendor-
specific CVs.  This recommendation was accepted.

       13.  Issue 30 - SSP message type for all generalized data 
            stream (GDS) variable exchanges
It was decided to keep a single capabilities exchange SSP message 
type.

       14.  Issue 33 - Which CVs can be repeated?
Agreed that only the NetBIOS name list and MAC address list can be 
repeated in a single capabilities exchange.

       15.  Issue 34 - Semantics of NetBIOS CV
A DLSw box may be capable of NetBIOS support, but may not be 
configured to use it at all or over a particular connection.  
Rather than writing a complex if/then table, Wayne will enhance 
text instead to specify that, if a box is not configured to use 
its NetBIOS support, it should say that it does not support 
NetBIOS.

       16.  Issue 36 - Removal of loop prevention CV
It was decided that, since DLSw Version 1 will not include loop 
prevention support, we will not specify a loop prevention CV yet.

    C.  Summary
Except for writing up the text to support the decisions the group 
made, there are no open action items for the capabilities RIGlet 
and it is ready to propose for AD.

VI.  Loop Prevention RIGlet
Choon Lee of 3Com, RIGlet coordinator, introduced Peter Gayek of 
IBM, who presented a new proposal for handling loop prevention.   
This proposal was posted on May 17.  

     A.  He provided a handout of the presentation, which was very 
similar to IBM's prior posting.  IBM will post a list of changes 
between the posting and the presentation as soon as possible.

     B.  IBM proposes an algorithm for a DLSw to discover whether 
it is part of a loop.  If a loop is detected, the switch will (at 
least temporarily) disable that transport connection from searches 
and from setup flows.

         1.  The algorithm is based on each DLSw being assigned by 
the user to a particular LAN region for each of its input ports.  
Phase 1 involves setting and learning its LAN regions.  

             a.  If two DLSw's can reach each other other than 
                 across the DLSw virtual ring, they will realize 
                 that they share a LAN region and disable the loop 
                 between them.

             b.  If they are accidentally assigned to different 
                 region IDs for the same region, they will 
                 negotiate to the LAN region of the DLSw with the 
                 higher MAC address.  (Adopt region ID that is
                 the "best idea.")

             c.  It was suggested that a DLSw use something like
                 its MAC address for all of its LAN regions, 
                 and negotiate to the highest MAC address if there
                 are duplicates on a region. (This avoids some 
                 administrative configuration effort.)

         2.  Some capabilities exchange support would need to be 
developed for this.  Phase 2 involves loop prevention capabilities 
exchange to report its LAN regions.

         3.  Phase 3 involves the algorithm, after the 
capabilities exchange.  The current algorithm involves three 
questions to test for loops.

             a.  First degree loop:  If I find a potential DLSw 
partner is attached to a LAN region I'm attached to, I will 
disable the transport connection between us.

             b.  Second degree loop:  If I find a potential DLSw 
partner is attached to a LAN region that an active partner of mine 
is attached to, I will disable the connection between us.

             c.  Third degree loop:  If I find a potential DLSw 
partner is attached to a LAN region to which another DLSw node on 
one of my LAN regions has a partner, I will disable the connection 
between us.

        4.  Phase 4 is for reporting and noticing changes in run-
time and rechecking (phase 3).

        5.  The biggest issue noticed at the meeting is that this 
proposal catches simple loops, but would require much more work to 
catch big loops (consisting of many DLSw's and LAN segments).  

        6.  Further work includes developing formats, refining 
"partial disabling", and handling instability during changes.  

        7.  Possible refinements include protocol or SAP-based 
extensions, SSP exchange of "disable" message, and pro-active 
finding and bringing up a parallel (disabled) transport connection 
if a good transport connection fails.

VII.  Priority/COS RIGlet
Gene Cox of IBM, RIGlet coordinator, discussed the scope of 
priority/COS support in DLSw.

    A.  Three types of priority "discriminators" were discussed:  

o  Protocol (e.g., SNA has higher priority than NetBIOS)
o  Circuit  (e.g., on each TCP connection, certain circuits
            are given higher priority)
o  Session  Priority is assigned based on either:
   -  LU type
   -  Bind MODENAME

    B.  It was decided that it would be less complex to prioritize 
over a single TCP connection than to institute multiple TCP 
connections (one for each COS to be provided).  The latter  
would allow intermediate routers to participate in prioritization, 
but only those that implement TCP/IP type of service (which is a 
minimal percentage of installed routers), so this idea was 
dropped.  

    C.  Because priority seems to be an important consideration 
for the users of several of the vendors present, it was decided to 
attempt to include this type of prioritization in Version 1 of 
DLSw.  IBM will post the proposal in the week after this meeting.  
Editor Alan Bartky will include the proposal in the proposed AD 
document.  If agreement is reached by the end of the AD review 
cycle (end of July), it will be included; else it will be dropped 
until Version 2.

VIII.  Conformance RIGlet
Burt Gearhart of ACT, RIGlet coordinator, managed this section of 
the meeting.

    A.  He discussed the issues/costs of developing a conformance 
test for DLSw.  Since there are relatively few vendors to share 
the cost, the cost may be prohibitive.

    B.  He noted the two primary questions DLSw testing must 
answer:

        1.  Do SNA devices operate as they used to without DLSw?

        2.  How is performance affected (by traveling across DLSw 
"cloud")?

    C.  He recommended that a solution like some components of 
ACT's SNA Development Test Facility (SDTF) could be used to at 
least confirm that DLSw is not interrupting the SNA sessions it 
supports and to measure the delay introduced by DLSw.

For example, one could test the "implementation-under-test" by 
first testing an SNA session directly on a LAN and then with a LAN 
on each side of two DLSw's:

SNA host------------------LAN-------------------SNA workstation
(w/SDTF)

SNA host---LAN---DLSw----TCP/IP----DLSw---LAN---SNA workstation
(w/SDTF)

The same could be done with SDLC/X.25 on both sides, and with all 
the mixes that DLSw supports (e.g., LAN on one side and SDLC/X.25 
on the other).

    D.  The group acknowledged that these would be more 
interoperability tests rather than conformance tests.

    E.  The group indicated that they may be interested in 
developing DLSw conformance tests and interoperability tests.

IX.  Closing

    A.  RIGlet summaries: consensus items, open issues, status

        1.  Connect - Ready to go to AD status with changes
            as noted above.

        2.  MIB - New coordinator selected.  Editor selected.
            Structure for MIB proposed, will be posted.  MIB
            group may meet at Interop in Atlanta (interim mtg).

        3.  Flow Control - Ready to go to AD status with changes
            as noted above.

        4.  Capabilities - Ready to go to AD status with changes
            as noted above.

        5.  Loop Prevention - New proposal presented by IBM.
            Will be posted for discussion and possible 
            inclusion in Version 2.

        6.  Priority / COS - IBM proposal will be written up and
            included in proposed AD document.  If agreement is
            not reached by end of AD review cycle (end of July)
            priority will be dropped from Version 1.

        7.  Conformance - Very early discussions.  Group may
            be interested in developing conformance tests and
            interoperability tests.  Group decided that proposed
            performance and base functioning testing is not
            sufficient for conformance testing.

        8.  DLSw - DLSw proposed AD document will be posted on
            July 11.

    B.  RIG schedule to CP for Version 1

06/27/94    Draft AD distributed at beginning of AIW5.

07/05/94    All follow-up comments committed to at AIW5 are 
            posted.

07/11/94    Draft AD with AIW5 input posted for 3-week review.

07/29/94    AD review ends.  Each coordinator gathers and 
            incorporates changes to RIGlet proposals. 
            Editor gathers all RIGlet reports to incorporate
            into final AD document.

08/05/94    AD achieved.  Draft AD with comments incorporated 
            becomes both final AD document and draft AP document.
            Draft AP document posted for 3-week review.

08/26/94    AP review ends.  Each coordinator gathers and 
            incorporates changes to RIGlet proposals. 
            Editor gathers all RIGlet reports to incorporate
            into final AP document.

09/02/94    AP achieved.  Draft AP with comments incorporated 
            becomes both final AP document and draft CP document.
            Implementers can build based on AP document.
            Draft CP document posted for 3-week review.

09/23/94    CP review ends.  Each coordinator gathers and 
            incorporates changes to RIGlet proposals. 
            Editor gathers all RIGlet reports to incorporate
            into final CP document.

09/30/94    CP achieved.  Draft CP with comments incorporated 
            becomes final CP document for DLSw Version 1.

Early       AIW6 - Group reports CP status to AIW chair.
October

October     Editor requests Informational RFC number, posts 
            document.

    C.  General Planning for Version 2 - Proposed by Chair
        and revised based on input at meeting but NOT yet
        approved by group.

06/30/94 to
09/30/94    Contributions solicited for conformance, 
            priority/COS, and loop prevention and, as needed, for
            connect, flow control, and capabilities

October 94  Proposals discussed at AIW6 (early October) and
            on network until mid-November. 
            (Version 1 scheduled to reach CP in early October.)

November 94 Coordinators post single proposal for each RIGlet 
            in mid-November.  More comments for two weeks.

December 94 Comments/changes incorporated by coordinators and
            editor into draft AD distributed at end of November.
            Draft AD with AIW6 input posted for 4-week review
            (due to winter holidays/vacations).

Jan 3 95    AD review ends.  Editor gathers all changes to 
            incorporate.

Jan 9 95    AD achieved. Draft AD with comments incorporated 
            becomes both final AD document and draft AP document.
            Draft AP document posted for review until AIW7
            (early February) (4-5 weeks).

Mid-Feb 95  AP review continues at AIW7 in February.  Editor 
            gathers all changes to incorporate.  Changes posted
            as revised AP draft and two more weeks review on
            network (for input from those not at meeting).

Feb 28 95   AP achieved.  Draft AP with comments incorporated 
            becomes both final AP document and draft CP document.
            Implementers can build based on AP document.
            Draft CP document posted for 3-week review.

Mar 21 95   CP review ends.  Editor gathers all changes to 
            incorporate.

April 1 94  CP achieved.  Draft CP with comments incorporated 
            becomes final CP document for DLSw Version 2.

June 94  AIW8 - DLSw chair reports CP status to AIW chair.

    D.  Scheduling for AIW6
There have been several complaints about the percentage of overlap 
of DLSw with the other AIW sessions, which defeats the initial 
value of DLSw meeting with AIW since participants also wanted to 
attend the AIW.

Louise Herndon Wells recommended a proposal that the DLSw meet for 
an extra half day before or after the next AIW (depending on 
whether its 2 1/2 days start in the morning or afternoon) and to 
specifically request of the AIW that we not overlap with the 
Architecture Reference SIG and the Primary LU BOF.  The group 
agreed to encourage this request.

DLSw Addenda
    Further information on data link switching standard 
    development effort

The DLSw chair, editors, and coordinators can be reached as 
follows:

DLSw chair:  Louise Herndon Wells         [email-masked]
             Internetwork Technology Institute  (408) 946-4625
DLSw editor:       Alan Bartky            [email-masked]
                  Sync Research                 (714) 588-2070
DLSw MIB editor:  David Chen              [email-masked]
                  IBM Corporation               (919) 254-6182 

Coordinators:
    Connect       Steve Klein             [email-masked]
                  IBM Corporation               (919) 254-5623
    MIB           Deirdre Kostick         [email-masked]
                  Bellcore                      (908) 758-4177
    Flow control  Shannon Nix             [email-masked]
                  Metaplex                      (919) 878-0811
    Capabilities  Wayne Clark             [email-masked]
                  Cisco Systems                 (415) 688-4625
    Loop prevent. Choon Lee            [email-masked]
                  3Com Corporation              (408) 764-5000
    Conformance   Burt Gearhart        [email-masked]
                  Applied Computer Technology   (214) 271-6550
    Priority/COS  Gene Cox                [email-masked]
                  IBM Corporation               (919) 254-5075

The main DLSw mail list is: 
    [email-masked]

The RIGlet mailing lists are:
    [email-masked]
    [email-masked]
    [email-masked]
    [email-masked]
    [email-masked]
    [email-masked]
    [email-masked]

Documents and lengthy proposals are available by 
anonymous FTP to:
    networking.cary.ibm.com
and looking in:
    /pub/standards/aiw/dlsw

Maillogs from the origin of this group for each RIGlet by 
anonymous FTP to:
    networking.cary.ibm.com
and looking in:
    /pub/standards/aiw/maillogs   
         (e.g., mib.mail, connect.mail...)

To be added to any of these lists, send a request to the 
list above and add 
"-request" before the @. 
Example:[email-masked]

To discover who is on these lists, connect by anonymous FTP to:
    networking.cary.ibm.com
and look in:
    /pub/standards/aiw/memberinfo/_____.member-list  
         (e.g., connect.member-list, mib.member-list)